A popular pattern of interaction between programming entities involves clients and servers. A client is any program that is capable of making a request to a server and waiting for a response. A server is any program that offers a service that may be requested. Generally, a server accepts a request from the client, the server performs a service in response to the request, and then the server returns a result to the client. The client may be located remotely from the server, although it need not be.
The client may make a request to the server to process a transaction. A transaction is a set of one or more operations that are performed as an atomic unit. For example, within a database system, a transaction may involve numerous database commands that cause numerous changes to a database. While the changes are actually made at different points in time, they are all considered “permanent” (i.e., committed) within the system at the same point in time.
During the course of processing a transaction, a server may store information about the transaction (“transaction information”) in a non-persistent storage, e.g., volatile memory. When the server commits a transaction, transaction information is written from the non-persistent storage to persistent storage, e.g., to a log file durably stored on disk. The transaction information durably stored in the log file may be used to produce consistent read blocks for transaction read purposes. Transaction information may also promote read consistency, transaction rollback, and database recovery by inclusion in a rollback segment. A rollback segment is a portion of the database that records the actions of a transaction that should be rolled back under certain circumstances.
Transaction information stored in volatile memory is not durably stored. For example, transaction information stored in volatile memory may be periodically overwritten. Further, transaction information stored in the volatile memory of a server will not survive a crash of the server. As a result, the server may use an entity, such as a log writer, to durably store transaction information stored in volatile memory to a persistent storage when the transaction associated with the transaction information is committed. A log writer is a processing entity that may periodically write transaction information from a non-persistent storage to a persistent storage, such as a log file durably stored on disk. A log writer may durably store transaction information for multiple transactions contemporaneously from volatile memory to a persistent storage.
A client process is a thread of execution running on the client. A client process on the client may initiate a request to process a transaction (“a transaction request”) on the server. The server, in servicing the transaction request, may assign a server process to process the transaction request. A server process is a thread of execution running on the server that may be assigned a unit of work. A server may employ a plurality of server processes that may collectively be referred to as a connection pool.
After a particular server process has finished processing a transaction, the transaction may be committed. Once a transaction has been committed, transaction information associated with the committed transactions may be durably stored from memory to a persistent storage. The server process processing the transaction notifies the log writer that transaction information for the particular transaction it is processing should be written from memory to a persistent storage. The server process that has handled the transaction waits (i.e., is “blocked”) until receiving notification from the log writer that the log writer has durably stored the transaction information before the server process notifies to the requesting client process that the transaction is completed.
The time between (1) when the server process requesting that transaction information be durably stored from memory to a persistent storage and (2) when the server process receives notification from the log writer the transaction information has been durable stored is referred to as the “log sync latency.” Reducing the log sync latency is desirable because the server process cannot perform any useful work while the server process is waiting to receive notification from the log writer that the transaction information has been persistently stored, because the server process is no longer performing work for the current transaction and the server process cannot be reassigned to perform work for another transaction.
It is undesirable to have server processes not performing useful work because the central processing unit (“CPU”) of the server is not being utilized to its potential. To increase the utilization of the CPU, additional server processes could be started to process additional work, however, this may also lead to unsatisfactory results, because the cost of context switching between processes increases as the number of processes increases.
Further, the operation of the log writer may result in undesirable operating system scheduling dynamics. When the log writer durable stores transaction information for multiple transactions, multiple server processes are each notified contemporaneously that transaction information for the transaction each server process is currently handling has been durably stored. As a result, multiple server processes become unblocked around the same time. Thus, in a short amount of time, a potentially large amount of server processes switch from being blocked to unblocked, which may negatively impact the quality of service offered by the server to the client.
Accordingly, there is an unaddressed need in the art for durably storing transaction information from memory to a persistent storage at a server without incurring the aforementioned problems.